In a mobile (cellular) communications network, (user) communication devices (also known as user equipment (UE), for example mobile telephones) communicate with remote servers or with other communication devices via base stations. In their communication with each other, communication devices and base stations use licensed radio frequencies, which are typically divided into frequency bands and/or time blocks.
In order to be able to communicate via the base stations, communication devices need to monitor control channels operated by the base stations. One of these control channels, the so-called physical downlink control channel (PDCCH) carries the scheduling assignments and other control information. The PDCCH serves a variety of purposes. Primarily, it is used to convey the scheduling decisions to individual communication devices, i.e. scheduling assignments for uplink and downlink communication.
The information carried on the PDCCH is referred to as downlink control information (DCI). Physical control channels, such as the PDCCH, are transmitted on an aggregation of one or several consecutive control channel elements (CCEs), where a control channel element corresponds to nine resource element groups (REGs). Each REG has four resource elements (REs).
Another control channel, the so-called physical random access channel (PRACH) is provided for synchronising transmissions between a communication device and the network (e.g. when setting up an initial access for the communication device and/or whenever re-synchronisation is necessary). In the current standard specification (from Rel-8), the resource (preamble, time, frequency) allocated to the PRACH is configured in advance and the applicable PRACH parameters are broadcast by the network as part of system information in the so-called System Information Block 2 (SIB2). One of the parameters specifies the so-called random access preamble, which consists of a cyclic prefix part and a sequence part. The length of the preamble (i.e. the overall length of the two parts combined) depends on the frame structure and the random access configuration. The preamble format is controlled by higher layers (via the SIB2). Thus, based on the parameters included in the SIB2, communication devices are able to initiate access with the network over the correct PRACH resource and using the appropriate parameters (e.g. transmit an appropriate preamble). Further details of the physical layer random access preamble can be found in section 5.7.1 of 3GPP Technical Specification (TS) 36.211, the contents of which are incorporated herein by reference.
When an idle mode communication device needs to communicate with other communication nodes, it needs to change its operation mode to the so-called radio resource control (RRC) connected mode (from RRC idle mode). In order to do so, the communication device performs a random access procedure with a suitable base station (e.g. a base station having the strongest signal and/or a base station that the communication device is authorised to use). The random access procedure includes the communication device selecting and transmitting to the base station (over the PRACH advertised via the SIB2) an appropriate preamble sequence along with a temporary identifier for identifying the communication device for the base station. If the base station does not receive the communication device's transmission successfully (e.g. because a plurality of devices are transmitting preambles at the same time resulting in a collision) and/or does not send an appropriate random access response, then the communication device is configured to send another preamble sequence after a predetermined delay (and possibly repeat this step until the base station responds). If the communication device's transmission is received successfully (e.g. its transmission does not collide with transmissions by others), then the base station sends an appropriate random access response (in which the base station identifies the communication device using the received temporary identifier) and allocates resources for the communication device for communicating with the network.
Thus, once the base station responds to a preamble transmission by the communication device, the communication device is able to request in its next message the establishment of an RRC connection (and/or the like) using the allocated resources. Once an RRC connection is established between the communication device and the base station, the communication device is able to communicate with other communication nodes via that base station (and via the core network) using the resources allocated by the base station.
Recent developments in telecommunications have seen a large increase in the use of machine-type communications (MTC) devices which are networked devices arranged to communicate and perform actions without human assistance. Examples of such devices include smart meters, which can be configured to perform measurements and relay these measurements to other devices via a telecommunication network. Machine-type communication devices are also known as machine-to-machine (M2M) communication devices.
MTC devices connect to the network (after performing an appropriate random access procedure, if necessary) whenever they have data to send to or receive from a remote ‘machine’ (e.g. a server) or user. MTC devices use communication protocols and standards that are optimised for mobile telephones or similar user equipment. However, MTC devices, once deployed, typically operate without requiring human supervision or interaction, and follow software instructions stored in an internal memory. MTC devices might also remain stationary and/or inactive for a long period of time. The specific network requirements to support MTC devices have been dealt with in the 3GPP TS 22.368 standard, the contents of which are incorporated herein by reference.
For the Release 13 (Rel-13) version of the standards relating to MTC devices, support for a reduced bandwidth of 1.4 MHz in downlink and uplink is envisaged. Thus, some MTC devices will support only a limited bandwidth (typically 1.4 MHz) compared to the total LTE bandwidth and/or they may have fewer/simplified components. This allows such ‘reduced bandwidth’ MTC devices to be made more economically compared to MTC devices supporting a larger bandwidth and/or having more complicated components.
The lack of network coverage (e.g. when deployed indoors), in combination with the often limited functionality of MTC devices, can result in such MTC devices having a low data rate and therefore there is a risk of some messages or channels, such as the PDCCH, not being received by an MTC device. In order to mitigate this risk, it has been proposed to increase the coverage of the PDCCH (and/or the evolved physical downlink control channel (EPDCCH) in Rel-13) to support such MTC devices (e.g. corresponding to 20 dB for frequency division duplex (FDD) transmissions).
One approach proposed for the enhancement of coverage, for so called ‘coverage enhanced MTC devices’, is the repetition of the same EPDCCH information (e.g. DCI) across multiple (e.g. two, three, four) subframes. In other words, for coverage enhanced MTC devices, the base station duplicates the EPDCCH information in the time domain (the base station re-transmits the same EPDCCH information in one or more subframes subsequent to the subframe in which that EPDCCH information is first sent). Such a coverage enhanced MTC device can be configured to combine the multiple copies of the (same) EPDCCH information received in the multiple subframes, and after combining the received information, the coverage enhanced MTC device is more likely to be able to decode the EPDCCH successfully than based on a single copy of the EPDCCH information.
In practice, MTC devices may be deployed in different locations and they may experience different channel conditions. Therefore, the number of repetitions (of the EPDCCH information) may need to be tailored for each device's situation or coverage level. Therefore, in order to facilitate such enhanced coverage, each MTC device will need to inform its serving base station of the amount of coverage required (e.g. 5 dB/10 dB/15 dB/20 dB coverage enhancement) to allow the base station to adjust its control signalling appropriately.
Ideally, however, physical layer control signalling (e.g. EPDCCH signalling) and higher layer common control information (e.g. SIB, random access response (RAR), paging messages, and/or the like) exhibit a high level of commonality between solutions for reduced bandwidth communication devices and solutions for coverage enhanced communication devices.
However, the inventors have realised that in order to support reduced bandwidth MTC devices in release 13, the provision of PRACH for the reduced bandwidth MTC devices needs to address a number of issues including, for example:                due to the reduced bandwidth of 1.4 MHz in downlink and uplink, the reduced bandwidth MTC devices cannot receive a PDCCH which is densely spread across an entire cell bandwidth (i.e. it may be transmitted over frequencies falling outside the 1.4 MHz supported by the MTC device);        consequently, reduced bandwidth MTC devices also cannot receive the scheduling assignment included in legacy RAR messages transmitted in the PDCCH (when it is spread across the entire cell bandwidth); and        the EPDCCH Common Search Space (CSS) can be defined in such a way that the physical broadcast channel (PBCH) indicates its location in time-frequency resources; in which case a reduced bandwidth MTC device will be unable to receive the CSS if either the PBCH or the EPDCCH is transmitted outside the 1.4 MHz band supported by the MTC device.        
It appears that there is no need to change the current PRACH design in order to support reduced bandwidth MTC devices in Rel-13, except that DCI for RAR messages will need to be transmitted in the EPDCCH Common Search Space (CSS), rather than in the PDCCH CSS, for MTC devices (since a Rel-13 MTC device will only monitor the EPDCCH CSS for potential dynamic scheduling of the common control information). However, it is yet to be resolved how a base station can efficiently and reliably identify a reduced bandwidth MTC device in Rel-13 so that the corresponding DCI (e.g. a RAR message) is transmitted in the EPDCCH CSS (for the bandwidth reduced MTC device).
In addition to the issues associated with reduced bandwidth MTC devices, the provision of PRACH for coverage enhanced MTC devices in Rel-13 will need to support the repetition of the PRACH, across multiple subframes in time domain, by using the existing LTE Rel-8 preamble formats in order to enhance the coverage of the PRACH channel and for backward compatibility.
Therefore, the provision of PRACH for coverage enhanced MTC UEs in Rel-13 also needs to address at least the following issues:                how to identify reduced bandwidth communication devices and coverage enhanced MTC communication devices in Rel-13 (so that a DCI/RAR can be transmitted in the EPDCCH CSS for such communication devices);        how to reduce the collision probability (contention problem) between reduced bandwidth communication devices and coverage enhanced (CE) communication devices, and also between different CE levels; and        because there is a lot of overhead associated with CE levels (due to time domain repetitions), it is desirable to avoid PRACH preamble collision with other coverage levels as well as reduced bandwidth communication devices (although collision/contention with the same CE level should be allowed).        